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(54) Method of managing memory allocation in a printing system 



(57) A method of managing memory allocation in a 
printing system including the steps of creating a plurality 
of blocks (306) in a memory (24) and designating each 
block with an identifier In response to a request from a 
client, a first set of identifiers, corresponding with a first 
set of blocks, is placed Into a database (304) by a re- 
source manager (300). The client then accesses the da- 
tabase and. by reference to the first set of identifiers, be- 
gins filling up the first set of blocks with image data. As 
each block is filled, the client transmits an interrupt signal 
to a controller (44). After a predesignated one of the first 
set of blocks has been filled, the controller causes the 
resource manager to place a second set of identifiers in 
the database so that the client can access the second 
set of identifiers as soon as it has completed filling the 
first set of blocks. 
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Description 

The present invention relates generally to a tech- 
nique of memory management for a printing system and, 
more particularly, to a method of managing memory al- 
location for the printing system which minimizes both 
processing overhead and memory fragmentation. 

Electronic printing systems typically include an input 
section, sometimes referred to as an input image termi- 
nal ("IIT"), a controller, sometimes referred to as an elec- 
tronic subsystem ("ESS") and an output section or print 
engine, sometimes referred to as an image output termi- 
nai ("lOT"). in one type of electronic printing system, 
manufactured by Xerox® Corporation, known as the 
DocuTech® electronic printing system, a job can be in- 
putted to the NT from, among other sources, a network 
or a scanner. An example of an NT with both network and 
scanner inputs is found in US-A-5,1 70,340. 

Since digital printing systems store images electron- 
ically, a significant amount of memory Is often required 
for storage. In a multifunctional digitai printing system, 
various clients, I.e. various input/output devices of the 
printing system, seek to use the memory. That is, input 
clients seek to access the memory for storing image data 
and output clients seek to access the memory for the 
sake of consuming image data. Without some sort of ar- 
rangement for controlling employment of the memory by 
these clients, operation of the system can be impaired 
greatly. For example, a client with relatively slow 
processing capability can monopolize use of the memory 
at the expense of a client with relatively fast processing 
capability. Moreover, the memory needs of a group of 
clients may vary, among individual clients, over time. In 
the area of computer architecture, it is known that mem- 
ory or resource management is a desirable approach for 
Insuring that allocation of memory among a group of cli- 
ents is performed in an orderly manner. 

US-A-5, 21 2,566 is directed toward a resource allo- 
cation scheme for a memory arrangement including disk 
and system memories, the system memory including a 
plurality of buffers. A system state controller communi- 
cates with the system memory, by way of a resource 
manager, and with a scanner, by way of a scan manage- 
ment arrangement, the scan management arrangement 
including a scan scheduler and a scan controller. In op- 
eration, the scanner, along with each client requesting 
use of the system memory, is allocated a set of buffers. 
During run time, the scanner fills buffers allocated to it 
with scanned data of a scan job, obtained by reading a 
document, and stores each filled buffer out to disk. If the 
scanner requires more buffers than are allocated to it, 
then a fault will occur. In response to the fault, a fault 
command flows from the scan controller to the system 
state controller, which system state controller, in turn, 
transmits a control command requesting the resource 
manager to adjust buffer allocation in the system mem- 
ory. Under ideal circumstances, the scanner receives the 
buffers it needs to complete the scan job. As disclosed. 



reallocation includes obtaining a previously allocated 
buffer from a client other than the scanner. 

While the resource management scheme of the '566 
patent Is well suited for its intended purpose, it appears 
s to require a fair amount of processing overhead since 
buffer allocation among clients must often be assessed 
in obtaining a free buffer for the scanner. It would be de- 
sirable to provide a resource management scheme 
which uses a minimum amount of processing overhead 
in obtaining and providing memory for a given client. Ad- 
ditionally, in the resource management scheme of the 
'566, all of the buffers allocated to a given client may not 
be used fully. This can lead to underutilization of memory 
space and even memory fragmentation. It would be de- 
sirable to provide a resource management scheme in 
which all memory space of the system memory is em- 
ployed in the most efficient manner possible. 

It is an object of the present invention to provide such 
a scheme. 

In accordance with one aspect of the present inven- 
tion there is provided a method of managing memory al- 
location in a printing system with a controller and mem- 
ory, the controller having a resource manager for man- 
aging use of the memory and the printing system sup- 
porting input clients, each input client seeking to store 
one or more images, in the form of image data, in the 
memory, comprising the steps of: partitioning at least a 
portion of the memory to create a plurality of blocks; pro- 
viding each of the plurality of blocks with an identifier, 
each identifier indicating a location of a block in the mem- 
ory; in response to a request from a selected input client, 
placing a first set of identifiers, corresponding with a first 
set of blocks, in a database; accessing the first set of 
identifiers with the selected input client; filling up one or 
more of the first set of blocks, with image data, by refer- 
ring to the first set of identifiers; transmitting an interrupt 
signal to the controller, with the selected Input client, 
each time one of the first set of blocks is filled; and in 
response to a designated one of the blocks being filled, 
placing a second set of Identifiers, corresponding with a 
second set of blocks, in the database, so that when the 
selected input client has filled up a last one of the first 
set of blocks, the selected input client accesses the sec- 
ond set of blocks, by reference to the second set of iden- 
tifiers and begins filling up a first block of the second set 
of blocks wherein memory allocation is accomplished 
with a minimum amount of communication between var- 
ious components of the printing system. 

In accordance with another aspect of the present in- 
vention there is provided a method of managing memory 
allocation in a printing system with an input client, the 
input client storing image data in memory for outputting 
an Image associated with the image data, comprising the 
steps of: providing to the input client, a first set of blocks 
Including a first block and a second block, wherein the 
second block Includes a first part and a second part; fill- 
ing up both the first block and the first part of the second 
block with image data, an end of the first part of the see- 
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ond block representing a corresponding end of a first im- 
age; and filling up the second part of the second block 
with image data, the image data in the second part of the 
second block corresponding with a second image, 
wherein the first image is different than the second image 
and usage of memory space for storing image data is 
maximized. 

These and other aspects of the invention will be- 
come apparent from the following description, the de- 
scription being used to illustrate a preferred embodiment 
of the invention when read In conjunction with the ac- 
companying drawings, in which:- 

Figure 1 is a block diagram depicting a multifunc- 
tional, network adaptive printing machine; 
Figure 2 is a block diagram of a video control module 
for the printing machine of Figure 1 ; 
Figure 3 is a block diagram of a transfer module used 
in conjunction with the printing machine of Figure 2; 
Figure 4 is a block diagram of a facsimile card used 
in conjunction with the printing machine of Figure 2; 
Figure 5 is a block diagram of a network controller 
for the printing machine of Figure 1 ; 
Figure 6 is a block diagram of a resource manage- 
ment scheme including a selected number of com- 
ponents from the block diagram of Figure 2; 
Figures 7-10 is a flow diagram illustrating some of 
the functionality of the resource management 
scheme of Figure 6; 

Figure 11 is a schematic representation of electronic 
precollation (EPC) memory being used in conjunc- 
tion with the resource management scheme of the 
present invention; 

Figure 12 is a schematic representation illustrating 
how partial blocks are employed, in the resource 
management scheme, to reduce memory fragmen- 
tation; 

Figure 13 is a schematic representation of a data- 
base format used in conjunction with the resource 
management scheme; and 
Figures 14-17 are schematic representations illus- 
trating how a combination of electronic precollation 
(EPC) and disk memory is used in conjunction with 
the resource management scheme. 

Referring to Figure 1. a multifunctional, network 
adaptive printing system is designated by the numeral 
10. The printing system 10 includes a printing machine 
12 operatively coupled with a network service module 
14. The printing machine 12 includes an electronic sub- 
system 1 6, referred to as a video control module (VCM), 
communicating with a scanner 18 and a printer 20. In 
one example, the VCM 16. which will be described in fur- 
ther detail below, coordinates the operation of the scan- 
ner and printer in a digital copying arrangement. In a dig- 
ital copying arrangement, the scanner 18 (also referred 
to as image input terminal (I IT)) reads an Image on an 
original document by using a CCD full width array and 



converts analog video signals, as gathered, into digital 
signals. In tum, an image processing system 22 (Figure 
2), associated with the scanner 18, executes signal cor- 
rection and the like, converts the corrected signals into 

s multi-level signals (e.g. binary signals), compresses the 
multi-level signals and preferably stores the same in 
electronic precollation (EPC) memory 24. 

Referring again to Figure 1 , the printer 20 (also re- 
ferred to as image output terminal (lOT)) preferably in- 

10 dudes a xerographic print engine. In one example, the 
print engine has a multi-pitch belt (not shown) which is 
written on with an imaging source, such as a synchro- 
nous source (e.g. laser raster output scanning device) 
or an asynchronous source (e.g. LED print bar). In a 

15 printing context, the multi-level image data is read out of 
the EPC memory 24 (Figure 2) while the imaging source 
is turned on and off. in accordance with the image data, 
forming a latent image on the photoreceptor. In tum, the 
latent image is developed with, for example, a hybrid 

20 jumping development technique and transferred to a 
print media sheet. Upon fusing the resulting print, it may 
be inverted for duplexing or simply outputted. tt will be 
appreciated by those skilled in the art that the printer can 
assume other forms besides a xerographic print engine 

25 without altering the concept upon which the disclosed 
embodiment is based. For example, the printing system 
10 could be implemented with a thermal ink jet or iono- 
graphic printer. 

Referring specifically to Figure 2, the VCM 1 6 is dis- 

30 cussed in further detail. The VCM 16 includes a video 
bus (VBus) 28 with which various I/O, data transfer and 
storage components communicate. Preferably, the VBus 
is a high speed, 32 bit data burst transfer bus which is 
expandable to 64 bit. The 32 bit implementation has a 

35 sustainable maximum bandwidth of approximately 60 
MBytes/sec. In one example, the bandwidth of the VBus 
is as high as 100 MBytes/sec, 

The storage components of the VCM reside in the 
EPC memory section 30 and the mass memory section 

40 32. The EPC memory section includes the EPC memory 
24, the EPC memory being coupled with the VBus by 
way of a DRAM controller 33. The EPC memory, which 
is preferably DRAM, provides expansion of up to 64 
MBytes, by way of two high density 32 bit SIMM modules. 

45 The mass memory section 32 includes a SCSI hard drive 
device 34 coupled to the VBus by way of a transfer mod- 
ule 36a As will appear, other I/O and processing com- 
ponents are coupled respectively to the VBus by way of 
transfer modules 36. It will be appreciated that other de- 

50 vices (e.g. a workstation) could be coupled to the VBus 
by way of the transfer module 36a through use of a suit- 
able interface and a SCSI line. 

Referring to Figure 3, the structure of one of the 
transfer modules 36 Is discussed in further detail. The 

55 illustrated transfer module of Figure 3 includes a packet 
buffer 38, a VBus interface 40 and DMA transfer unit 42 . 
The transfer module 36, which was designed with "VH- 
SIC Hardware Description Language (VHDL), is a pro- 
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grammable arrangement pernnitting packets of image 
data to be transmitted along the VBus at a relatively high 
transfer rate. In particular, the packet buffer is program- 
mable so that the segment or packet can be varied ac- 
cording to the available bandwidth of the VBus. In one 
example, the packet buffer can programmed to handle 
packets of up to 64 Bytes Preferably, the packet size 
would be reduced for times when the VBus is relatively 
busy and increased for times when activity on the bus is 
relatively low. 

Adjustment of the packet size is achieved with the 
VBus interface 40 and a system controller 44 (Figure 5). 
Essentially, the VBus interface is an arrangement of log- 
ical components, including, among others, address 
counters, decoders and state machines, which provides 
the transfer module with a selected degree of intelli- 
gence. The interface 40 communicates with the system 
controller to keep track of desired packet size and, in 
turn, this knowledge is used to adjust the packet size of 
the packet buffer 38, in accordance with bus conditions. 
That is, the controller, in view of its knowledge regarding 
conditions on the VBus 28, passes directives to the in- 
terface 40 so that the interface can adjust packet size 
accordingly. Further discussion regarding operation of 
the transfer module 36 is provided below 

More particularly, each DMA transfer unit employs a 
conventional DMA transfer strategy to transfer the pack- 
ets. In other words, the beginning and end addresses of 
the packet are used by the transfer unit in implementing 
a given transfer. When a transfer is complete, the Inter- 
face 40 transmits a signal back to the system controller 
44 so that further infomaatlon, such as desired packet 
size and address designations, can be obtained. 

Referring to Figures 1 and 2, three I/O components 
are shown as being coupled operatively to the VBus 28, 
namely a FAX module 48, the scanner or NT 1 8, and the 
printer or lOT 20; however, it should be recognized that 
a wide variety of components could be coupled to the 
VBus by way an expansion slot 50. Referring to Figure 
4, an implementation for the FAX module, which is cou- 
pled to the VBus 28 by way of transfer module 36b, is 
discussed in further detail. In the preferred embodiment, 
a facsimile device (FAX) 51 includes a chain of compo- 
nents, namely a section 52 for performing Xerox adap- 
tive compression/decompression, a section 54 for scal- 
ing compressed image data, a section 56 for converting 
compressed image data to or from CCITT format, and a 
modem 58, preferably manufactured by Rockwell Cor- 
poration, for transmitting CCITT formatted data from or 
to a telephone, by way of a conventional communication 
line. 

Referring still to Figure 4, each of the sections 52, 
54 and 56 as well as modem 58 are coupled with the 
transfer module 36b by way of a control line 60. This per- 
mits transfers to be made to and from the FAX module 
48 without involving a processor. As should be under- 
stood, the transfer module 36b can serve as a master or 
slave for the FAX module in that the transfer module can 



provide image data to the FAX for purposes of transmis- 
sion or receive an incoming FAX. In operation, the trans- 
fer module 36b reacts to the FAX module in the same 
manner that it would react to any other I/O component. 

5 For example, to transmit a FAX job, the transfer module 
36b feeds packets to the section 52 through use of the 
DMA transfer unit 42 and, once a packet is fed, the trans- 
fer module transmits an interrupt signal to the system 
processor 44 requesting another packet. In one embod- 

10 iment, two packets are maintained in the packet buffer 
38 so that "ping-ponging" can occur between the two 
packets. In this way, the transfer module 36b does not 
run out of image data even when the controller cannot 
get back to it immediately upon receiving an interrupt sig- 

is nal. 

Referring again to Figure 2, the NT 18 and tOT 20 
are operatively coupled to the VBus 28 by way of transfer 
modules 36c and 36d. Additionally, the NT 18 and the 
lOT 20 are operatively coupled with a compressor 62 and 

20 a decompressor 64, respectively. The compressor and 
decompressor are preferably provided by way of a single 
module that employs Xerox adaptive compression de- 
vices. Xerox adaptive compression devices have been 
used for compression/decompression operations by 

25 Xerox Corporation in its DocuTech® printing system. In 
practice, at least some of the functionality of the transfer 
modules is providedby wayof aSchannel DVMA device, 
which device provides local arbitration for the compres- 
sion/decompression module. 

30 As further illustrated by Figure 2, the scanner 18, 
which includes the image processing section 22. is cou- 
pled with an annotate/merge module 66. Preferably the 
image processing section includes one or more dedicat- 
ed processors programmed to perform various desired 

35 functions, such as image enhancement, threshold- 
ing/screening, rotation, resolution conversion and TRC 
adjustment. The selective activation of each of these 
functions can be coordinated by a group of image 
processing control registers, the registers being pro- 

40 grammed by the system controller 44. Preferably, the 
functions are arranged along a "pipeline" in which image 
data is inputted to one end of the pipe, and image proc- 
essed image data is outputted at the other end of the 
pipe. To facilitate throughput, transfer module 36e is po- 

45 sitloned at one end of the image processing section 22 
and transfer module 36c is positioned at another end of 
the section 22. As will appear, positioning of transfer 
modules 36c and 36e in this manner greatly facilitates 
the concurrency of a loopback process. 

50 Referring stilt to Figure 2, arbitration of the various 
bus masters of the VCM 16 is implemented by way of a 
VBus arbiter 70 disposed in a VBus arbiter/bus gateway 
71. The arbiter determines which bus master (e.g. FAX 
module. Scanner, Printer, SCSI Hard Drive, EPC Mem- 

55 ory or Network Service Component) can access the 
VBus at one given time. The arbiter is made up of two 
main sections and a third control section. The first sec- 
tion, i.e., the "Hi-Pass" section, receives input bus re- 
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quests and current priority selection, and outputs a grant 
corresponding to the highest priority request pending. 
The current priority selection input is the output from the 
second section of the arbiter and is referred to as "Priority 
Select". This section implements priority rotation and se- 
lection algorithm. At any given moment, the output of the 
logic for priority select determines the order in which 
pending requests will be serviced. The input to Priority 
Select is a register which holds an initial placement of 
devices on a priority chain. On sen/icing requests, this 
logic moves the devices up and down the priority chain 
thereby selecting the position of a device's next request. 
Control logic synchronizes the tasks of the Hi- Pass and 
the Priority Select by monitoring signals regarding re- 
quest/grant activity. It also prevents the possibility of race 
conditions. 

Referring to Figure 5, the network sen/ice module 
1 4 is discussed in further detail. As will be recognized by 
those skilled in the art, the architecture of the network 
service module is similar to that of a known "PC clone". 
More particularly, in the preferred embodiment, the con- 
troller 44. which preferably assumes the form of a 
SPARC processor, manufactured by Sun Microsystems. 
Inc., is coupled with a standard SBus72. In the illustrated 
embodiment of Figure 5. a host memory 74, which pref- 
erably assumes the form of DRAM, and a SCSI diskdrive 
device 76 are coupled operatively to the SBus 72. While 
not shown in Figure 5, a storage or I/O device could be 
coupled with the SBus with a suitable interface chip. As 
further shown in Figure 5, the SBus is coupled with a 
network 78 by way of an appropriate network interface 
80. In one example, the network interface includes all of 
the hardware and software necessary to relate the hard- 
ware/software components of the controller 44 with the 
hardware/software components of the network 78. For 
instance, to interface various protocols between the net- 
work service module 1 4 and the network 78, the network 
interface could be provided with, among other software. 
Netware® from Novell Corp. 

In one example, the network 78 includes a client, 
such as a workstation 62 with an emitter or driver 84. In 
operation, a user may generate a job including a plurality 
of electronic pages and a set of processing instructions. 
In turn, the job is converted, with the emitter, into a rep- 
resentation written in a page description language, such 
as PostScript. The job is then transmitted to the controller 
44 where it is interpreted with a decomposer, such as 
one provided by Adobe Corporation. 

Referring again to Figure 2, the network service 
module 1 4 is coupled with the VCM 1 6 via a bus gateway 
88 of the VBus arbiter/bus gateway 71 . In one example, 
the bus gateway comprises a field programmable gate 
array provided by XI LINX corporation. The bus gateway 
device provides the interface between the host SBus and 
the VCM VBus. It provides VBus address translation for 
accesses to address spaces in the VBus real address 
range, and passes a virtual address to the host SBus for 
virtual addresses in the host address range. A DMA 



channel for memory to memory transfers is also Imple- 
mented in the bus gateway. Among other things, the bus 
gateway provides seamless access between the VBus 
and SBus, and decodes virtual addresses from bus mas- 
5 ters, such as one of the transfer modules 36, so that an 
identifier can be obtained from a corresponding slave 
component. It will be appreciated by those skilled in the 
art that nnany components of the printing system 10 are 
implemented in the form of a single ASIC. 

Referring to Figures 2, 3 and 5, further discussion 
regarding DMA transfer of each of the transfer modules 
36 is provided. In particular, in one example, the images 
of a job are stored in the host memory 74 as a series of 
blocks. Referring to Figure 16, a series of blocks is 
shown as being stored in the EPC memory 24. Prefera- 
bly, each block comprises a plurality of packets. In oper- 
ation, one of the transfer modules 36 is provided, by the 
controller 44, with the beginning address of a block and 
the size of the block. In tum, for that block, the transfer 
module 36 effects a packet tranter and increments/dec- 
rements a counter. This procedure is repeated for each 
packet of the block until the interface 40 determines, by 
reference to the counter, that the last packet of the block 
has been transferred. Typically, for each stored image, 
several blocks are transferred, in a packet-by-packet 
manner, as described immediately above. 

Referring to Figure 6 a scheme for managing mem- 
ory allocation, i.e. a resource management scheme, is 
Illustrated. More particularly, the controller 44 includes a 
resource manager 300, while the host memory 74 in- 
cludes a pair of lists 302, referred to respectively as the 
Iree block lisf and the Iree partial block list", and a da- 
tabase ("db") 304. The resource manager is implement- 
ed by way of suitable algorithms, the details of which will 
be discussed in further detail below, and the significance 
of the lists and the database, relative to the resource 
management scheme, will also be discussed below. Ad- 
ditionally the EPC memory 24 and the SCSI hard drive 
("disk") 34 are shown as being comprised of blocks 306. 
A discussion of a methodology for forming and allocating 
memory blocks follows: 

Referring to Figures 6-10, the algorithms tor imple- 
menting the resource management scheme are dis- 
cussed. Initially, at step 308, the EPC memory 24 is par- 
titioned into a series of the blocks 306. A partitioned set 
of memory blocks is also shown in Figure 1 1 . Preferably, 
the block size is varied in accordance with factors, such 
as image size to be stored. For example, if a location 
generally copies complex documents which results in 
poorly compressed (large) image, the block size can be 
increased. As will appear from the discussion below, in- 
creased block size will result in fewer interrupts by a cli- 
ent (e.g. scanner 18) of the controller 44. 

Each block Is then provided with identification infor- 
mation (step 310), such as block ID, block address and 
block size, which identification information is placed, at 
step 312, in the free block list. Preferably, each list in the 
host memory 74 is a linked list of structures. At step 31 6, 
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the resource management system waits for a memory 
request from a client. In the present context, a client is 
an Input or output device encompassed by the printing 
system 10 (Figures 1 ,2 and 5). A client initiates a request 
by transmitting a suitable request or interrupt signal to 
the controller 44. Upon receiving a request signal, the 
controller determines, via step 316, whether the client is 
an input client. If the client is an input client, then the proc- 
ess proceeds to step 318, otherwise the process pro- 
ceeds directly to step 320 (Figure 9) where an output cli- 
ent request is serviced. 

Assuming the requesting client is an input client, the 
resource manager 300 examines the free partial block 
list to determine if a partial block is available for the re- 
questing client. Referring to Figure 12, an example of the 
allocation of a partial block to the beginning of an image 
will be discussed. In particular, at system initialization, 
no partial block is available for an image 1 of a job. After 
Image data for image 1 is delivered to the memory, how- * 
ever, a partial, unfilled block may remain. As shown in 
Figure 12, and explained in further detail below, the par- 
tially unfilled block, with its corresponding identifier is 
made available for use with the next image. 

Returning to Figure 7, if a partial, unfilled block is 
available, then it is designated with an Identifier and, at 
step 322, placed in the db 304. Next, at step 324, the 
resource manager consults the free block list to deter- 
mine if a nominal number of blocks are available for use 
by the input client. In the preferred embodiment, each 
client is assigned a value corresponding to the number 
of nominal blocks to which it Is entitled. In one example, 
assignment is based on the processing speed of the re- 
questing client That is, per each request, it may be de- 
sirable to provide fast processing clients with more 
blocks than slow processing clients. In one situation, the 
nominal number of blocks to be assigned a requesting 
client may not be available in the free block list. In this 
situation, the resource manager may provide the re- 
questing client with one or more partial blocks until a 
whole block becomes available. 

Assuming the nominal number of blocks Is available, 
at step 326 the resource manager wilt place appropriate 
identifiers (i.e. information identifying both a first address 
and a size of each block) in the db 304. Referring to Fig- 
ure 1 3, a suitable database structure for use with the dis- 
closed embodiment Is shown. The database Is construct- 
ed in a hierarchical scheme in which jobs are linked to 
images and images are linked to blocks. In one example, 
where the client's storable image data is associated with 
a first image (I.e. "Image 1) of a first job (Le. "JOB 1"), 
then the first block identifier is placed at the location des- 
ignated as "Block 1 Address". Subsequently, the client 
will access the database and, at step 328 (Figure 7), lo- 
cate the address of the first available block. The client 
will then, in cooperation with, for example, one of transfer 
modules 36, fill up the located block. When the scanner 
Is sen/ing as the client, the scanner will initiate a DMA 
transfer, with EPC memory 24, via the transfer module 



36D (Figure 2). Referring again to Figure 14, the scanner 
is shown as using the EPC memory in conjunction with 
other clients. While the block 306A is shown as being a 
whole block, it will be understood that, in many instances, 
s it would be a partial block. 

The printing system 1 0 offers the advantageous fea- 
ture of storing jobs, intended to be outputted as multiple 
sets, on disk. In this way EPC memory can be made 
available to multiple clients in a relatively short time in- 
terval. Referring to step 332 of Figure 8, when disk stor- 
age is desired, each stored block is copied to disk 34 
(also see step 334 of Figure 8). Referring to Figure 14, 
a graphic representation demonstrating the relationship 
between EPC memory and disk is provided. 

As further shown in Figure 14, preferably, a mini- 
mum amount of input image pages, intended for printing, 
are buffered prior to printing. This has been found to be 
advantageous since a printer typically processes image 
data at a rate much greaterthan that of most input clients, 
such as the scanner. In the illustrated embodiment of Fig- 
ure 15, a variable buffer zone 336 is maintained for the 
scan client. This buffer zone is used to move image di- 
rectly to disk, which enables the system to continue 
scanning without stopping. It will be appreciated that the 
variable zone can be used by clients, other than the 
scanner 18, to facilitate storage. 

Referring again to Figure 8, the input client transmits 
an interrupt signal to the controller, at step 338, when a 
block has been filled with image data. Alternatively, the 
input client could be provided, in advance, with pointers 
to lists of block addresses. In this way, the input client 
would read, without controller intervention, the locations 
of blocks to be used. 

A determination is made at step 340 as to whether 
a full image has been written into EPC memory 24. As- 
suming that the end of the image has not been reached, 
it is determined, at step 342, whether another nominal 
number of blocks is required. It should be appreciated 
that, typically, when a client requires a nominal number 
of blocks, the resource manager provides it with a set of 
plural blocks. In application, those blocks follow a se- 
quence and one of the blocks in the sequence is identi- 
fied as a "relative last block" which, when reached, indi- 
cates that another set of blocks Is required. The position 
of the relative last block is variable in that it need not, in 
absolute terms, be the last block of the set. If the relative 
last block has not been reached, then the process loops 
back to step 328 where the db 304 (Figure 6) is accessed 
so that the client can locate the next block to be filled. 
On the other hand, if the relative last block has been 
reached, then the process loops back to step 324 for ob- 
taining at least a part of another block set. 

Referring still to Figure 8, if it is determined, at step 
340, that a full image has just been written into memory, 
then a series of steps Is performed to prepare for the re- 
ceiving of another image. First, the resource manager 
300 (Figure 6) determines, with step 344, if all of the full 
blocks have been used by the input client. If not, then the 
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identifier ot each surplus whole block is placed in the free 
block list (step 348), otherwise the process proceeds to 
step 350 where the resource manager determines if the 
image ends on a partial block. Referring again to Figure 
12. an example of how an image might end at a partial 
block Is shown for the "Image r. In the preferred em- 
bodiment, the size of the unused part of Image 1 is then 
determined in accordance with step 352 of Figure 8. Re- 
ferring to Figure 9, if the size of the partial block Is greater 
than a selected minimum size (step 354), then an iden- 
tifier is assigned to the partial block (step 356) and placed 
in the free partial block list so that the partial block can 
be used to receive image data from another image, such 
as the "Next Image" of Figure 12. For those cases in 
which a given partial block is smaller than a selected min- 
imum, the given partial block is saved for "garbage col- 
lection", the significance of which will be described be- 
low. 

At steps 320 and 360, the preferred methodology ac- 
commodates for the needs of an output client, such as 
a printer. Regarding step 360, the output client is prefer- 
ably "told" where the image data, intended for use in out- 
putting, resides. In this way, the output client can read 
the image data from the EPC memory. Additionally, as 
shown in Figure 14, an output operation can be executed 
just before or after an input operation. 

Referring to Figures 1 4, 1 6 and 1 7, an application of 
the the present memory management scheme, with re- 
spect to the printing client, is discussed In further detail. 
In the illustrated embodiments of Figures 14, 16 and 17, 
a given job, intended to be printed in multiple sets, Is 
shown as including six images. In Figure 14, the first 
three images are buffered and copied to disk. In Figure 
16, writing of images, to memory, continues concurrent 
with the reading of first and second image blocks by the 
printer. While the read/write operations are not "concur- 
rent", in absolute terms, they appear, to a system oper- 
ator, as being concurrent. 

In Figure 17, the end of the job Is written into EPC 
memory at blocks 306B, 306C and 306D, while the be- 
ginning of the printing of a second set is initiated at block 
306E. For the printing of the second set, the Image 2, 
along with the block for 1 D need not be copied from disk. 
As should be recognized, the EPC memory and disk 
function in a manner comparable to a ring buffering ar- 
rangement in that image data from disk can be written 
over image data in the EPC memory, continually, in order 
to form a desired number of sets. 

At step 362 (Figure 9), It is determined whether an 
appropriate time has arrived for "garbage collection". In 
the present context, garbage collection refers to combin- 
ing "spent blocks", i.e. blocks having image data already 
"consumed" by an output client, for future use. In one 
example, a check for garbage collection is performed af- 
ter a predesignated number of images have been print- 
ed. More particularly, garbage collection is performed as 
a background task, i.e. during a noncritical time of a job 
cycle. 



To implement garbage collection, the possibility of 
block combination is checked at step 364 and partial 
blocks are combined, if possible, at step 366. It follows 
that block combination constitutes, in one example, link- 
s ing partial blocks with references. As blocks are formed 
from partial blocks (step 368), some partial block identi- 
fiers will be discarded and the resulting whole block will 
be placed in the free block list. If garbage collection Is 
not performable, the process proceeds to step 372. 

At step 372, a check is performed to detemnine if the 
currently completed image is the last image in the job. If 
the image Is not the last image, then the process loops 
back to step 316 where the input/output client accesses 
the db 304 for another block identifier, assuming that the 
client is ready. If, on the other hand, the job is complete, 
then a determination Is made, at step 374, as to whether 
repartitioning is required. Repartitioning Is performed 
(step 376) until a suitable block size is obtained. Subse- 
quent to repartitioning the process loops back to step 
316. 

Numerous features of the above-disclosed embod- 
iment will be appreciated by those skilled in the art: 

First, the disclosed resource management scheme 
functions with a minimum amount of processing over- 
head. In particular, per a request by a client, block iden- 
tifiers are placed at selected locations in a database. In 
turn, a selected client can access the database, deter- 
mine where available blocks exist in memory, by refer- 
ence to the block identifiers, and begin filling those 
blocks. As the client fills the blocks, it signals a controller 
and. In response to the signals, the controller indicates 
to a resource manager when to place more block iden- 
tifiers in the database for the selected client. The process 
of providing blocks is transparent to the selected client 
and the resource manager is not required to possesses 
any significant knowledge about memory allocations of 
system clients In order to service the selected client ap- 
propriately. 

Second, memory utilization of the system is en- 
hanced in that memory blocks are employed in a partic- 
ularly efficient manner. That is, unused blocks, whether 
they be partial or whole blocks, are placed in one or more 
free lists as soon as a given client ceases to have an 
immediate need for them. In turn, unused free blocks are 
allocated to other clients, in an expeditious manner and 
partial blocks are, in many instances, used to store the 
beginning and end parts of an image. I n this way memory 
fragmentation is minimized and memory space is made 
available to clients, who have an urgent demand for it, 
as soon as possible. 

Third, the resource management technique is flexi- 
ble in that a wide variety of system parameters, such as 
nominal block size, number of blocks allocated to a given 
client at one time, and block allocation timing are varia- 
ble. In this way, the attendant printing system can ac- 
commodate for varying input/output demands. Prefera- 
bly, the system can keep track of compression ratios and 
adjust the variables to maximize performance for a par- 
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ticular location's majority usage. For example, if a loca- 
tion generally copies complex documents, which results 
In poorly compressed (large) images, the block size can 
be increased. Use of increased block size will resutt in 
fewer interrupts to the controller. Moreover, the system 
can. among other things, adjust block allocation accord- 
ing to individual client processing capability and predict 
the moment at which blocks, for a given client, should be 
made available. 

Finally, the resource management scheme can be 
used to coincidentally manage volatile and nonvolatile 
memory in a manner that maximizes the functionality of 
the volatile memory, which volatile memory may be lim- 
ited in space. Through efficient management of volatile 
and nonvolatile memory, even a job, having a size great- 
er than that of the volatile memory (e.g. EPC memory) 
can be outputted in multiple sets with relatively little deg- 
radation in output rate. Moreover, volatile and nonvolatile 
memory can be used, conjunctively, to insure that even 
complex documents, having much greater size than that 
of the volatile memory, can be stored by a given input 
client without impairing operation of that given input cli- 
ent. 



Claims 

1 . A method of managing memory allocation in a print- 
ing system with a controller and memory, the con- 
troller having a resource manager for managing use 
of the memory and the printing system supporting 
input clients, each input client seeking to store one 
or more images, in the form of image data, in the 
memory, comprising the steps of: 

partitioning at least a portion of the memory to 
create a plurality of blocks; 
providing each of the plurality of blocks with an 
identifier, each identifier indicating a location of 
a block in the memory; 

in response to a request from a selected input 
client, placing a first set of identifiers, corre- 
sponding with a first set of blocks, in a database; 
accessing the first set of identifiers with the 
selected input client; 

filling up one or more of the first set of blocks, 
with image data, by referring to the first set of 
identifiers; 

transmitting an interrupt signal to the controller, 
with the selected input client, each time one of 
the first set of blocks is filled; and 
in response to a designated one of the blocks 
being filled, placing a second set of identifiers, 
corresponding with a second set of blocks, in 
the database, so that when the selected input 
client has filled up a last one of the first set of 
blocks, the selected input client accesses the 
second set of blocks, by reference to the second 



set of identifiers and begins filling up a first block 
of the second set of blocks wherein memory 
allocation is accomplished with a minimum 
amount of communication between various 
5 components of the printing system. 

2. The method of claim 1, wherein said filling step 
includes filling the first set of blocks with image data 
generated from a scan sen/ice, the scan service 

10 Including a scanning apparatus for converting infor- 
mation disposed on a document, to the image data. 

3. The method of claim 1, wherein the first set of blocks 
Includes a last block with said step of placing second 

15 set of identifiers including placing the second set of 
identifiers into the database after the last block has 
been filled with image data. 

4. The method of claim 1, further comprising the step 
20 of outputting a corresponding job, including one or 

both of the first and second block sets, with an output 
client. 

5. The method of claim 1, in which all of a filled block 
25 is used to print part of a corresponding job, further 

comprising the step of placing an identifier, associ- 
ated with the used, filled block, in a first list. 

6. The method of claim 1 further comprising the step 
30 of repartitioning the memory, after a selected 

number of blocks have been filled, for changing 
block size in accordance with varying image size of 
individual images being stored in memory. 

35 7. A method of managing memory allocation in a print- 
ing system with an input client, the input client stor- 
ing image data in memory for outputting an image 
associated with the image data, comprising the 
steps of; 

40 

providing to the input client, a first set of blocks 
including a first block and a second block, 
wherein the second block includes a first part 
and a second part; 

45 filling up both the first block and the first part of 

the second block with image data, an end of the 
first part of the second block representing a cor- 
responding end of a first image; and 
filling up the second part of the second block 

50 with image data, the image data in the second 

part of the second block corresponding with a 
second image, wherein the first image is differ- 
ent than the second image and usage of mem- 
ory space for storing image data Is maximized. 

55 

8. The method of claim 7, further comprising the steps 
of: 
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designating the second part of the second block 
with an identifier; 

placing the identifier in a partial block list, said 
second part filling up step including accessing 
the partial block list, with the input client, to 5 
determine a space, In memory, to which the 
image data of the second image is to be trans- 
mitted. 

9. The method of claim 7, in which the first set of blocks 
includes a third block and the third block remains 
unfilled subsequent to the second part being filled 
further comprising the steps of: 

designating the third block with an identifier; and is 
accessing the third block identifier with the input 
client for filling the third block with image data 
from the second image. 

10. The method of claim 7, in which the input client pos- 20 
sesses a processing capability and the first set of 
blocks includes a selected number of blocks, further 
comprising the step of adjusting the selected 
number of blocks as a function of the input client 
processing capability. 25 

11. The method of claim 7, wherein said filling step 
includes filling the first block and the first part of the 
second block with image data generated from a scan 
service, the scan service including a scanning appa- 50 
ratus for converting information disposed on a doc- 
ument, to the image data. 



35 



40 



4S 



50 



55 



9 



EP 0 704 792 A1 

t 



14 



Network 
Service 
Module 



10 



16 




Video Control Module 
(VCM) 



irji 



I- 



^12 



Scanner 



Printer 



18 20 



FIG. 1 



40 



f 




Packet Buffer 


VBus 


DMA 


Interface 


Transfer Unit 







36 



42 



FIG. 3 



10 



EP 0 704 792 A1 




11 



EP 0 704 792 A1 




12 



EP 0 704 792 A1 




13 



EP 0 704 792 A1 



322' 



(£> 



Partition Memory 
into Blocks 



I 



Provide Each Block with 
Identification 
Information 



Place Identification 
Information in Free List 



'308 



'310 



'312 



316 



318 




■0 



320 



Place Partial Block 
Identifier in Database 
(db) 



324 




326 

L 



Place Corresponding 
ldentifiers(s)in db 







FIG. 7 



Input Client Locates 
Memory Block(s)« by 
References to db and 
Writes Image Data to 
Currently Available 
Block 

— I — 

To Fig. 8 



14 



EP 0 704 792 A1 



From Fig. 7 i 



332 

No 



Disk 



^^N^Requested ^.^^ 
[Yes 




Copy Filled Block 
to Disk 






, ^ 




Input Client Notifies 
Controller that 
Block is Filled 



'334 



'338 




Place Corresponding 
Identifer in Full 
Block List 



350 




Determine Size of 
Partial Block 



"T" 

To Fig. 9 



'352 



FIG. 8 



15 



EP 0 704 792 A1 



From Fig. 6 



354 



Partial 
Block Greater^ 
than Minimum 
Size 
?^ 



356- 



& 



Assign Identifier, to 
Partial Block Remainder 
and Place Same in 
Free list 



320 



360' 



366^ 




Transmit Block(s) to 
Designated Output 
Destination 



362 



364 




Combine Partial 
Blocks 



T 



70 Fig, 10 



V 

© 



FIG. 



16 



EP 0 704 792 A1 



From Fig. 9 



Reassign Identifier(s) 
and Revise List 



& 



& 



Yes 



376 



^368 



•372 




Yes 




374 



Repartition 
Memory 



FIG. 10 



17 



EP 0 704 792 A1 




18 



EP 0 704 792 A1 










lock 








f 

# 

1 





























«< 


t 




IN 








cn 


— ► 


m 




E 

























II 


a < 







t 



± 




t 

• 
• 

1 





(A 






tA 




(A 






tA 




a; 






o; 








u 


"O 




no 








00 


< 






< 


















4 


a; 




01 


oi 




Oi 


ra 


► 




E 




E 












19 



EP 0 704 792 A1 




20 




21 



EP 0 704 792 A1 



ID 



E] 
IKl 

H 
H 

[E] 



< 







f 1 












K 










a. 
o 














0 












H 




H 


o c 


H 




H 












0 





22 



EP 0 704 792 A1 




23 



EP 0 704 792 A1 



European Patent EUROPEAN SEARCH REPORT """"" 

EP 95 30 6919 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Catecory 



Citatioa of dociuntot with indicatioii, where appropriate, 
of fctevant passages 



EP-A-0 550 158 (CANON KABUSHIKI KAISHA) 



* figures 5>6 * 

* column 2, line 17 



line 34 * 

* column 7, line 3 - line 47 * 

* column 9, line 9 - column 10, line 12 * 

WO-A-91 06058 (UNISYS CORPORATION) 

* figures 1,12A-12C * 

* figures 14A-14D * 

* page 12, line 1 
page 75, line 1 



page 84, line 22 - line 26 



page 13, line 17 
page 78, line 1 * 



The present search report has been drawn up for aU daims 



Relevant 
to daim 



CLASSlHCAnON OF THC 
APPUCATION (Int.CL6) 



1,4,6,7. 
10 
2,8 



2,8 
1-8.10 



G06F3/12 



TECHNICAL FIELDS 
SEARCHED <liil.a.6) 



G06F 



FUcaafuarck 

THE HAGUE 



Date at coapldlM at Cke levck 

15 January 1996 



CATEGORY OF OTED DOCUMENTS 

X : particularly relevant if taken alone 

Y : partiailariy relevant if combined with another 

dooinient of the same categoty 
A : technological back^ound 
O : Boo-iftitten disdosure 
P : intenaediate docuraent 



Weiss, P 



T : theory or principle underlying the inventioa 
E : earlier patent document, but published on, or 

ifter the filing date 
D : document dted io the appllcatlao 
L : document dted for other reasons 

& I member of the same patent family, correspoadios 
document 



24 



(19) 



J 



Europiisches Patentamt 
European Patent Office 
Office europeen des brevets 



(12) 



(45) Date of publication and mention 
of tlie grant of the patent: 
13.06.2001 Bulletin 2001/24 

(21) Application nunnber: 95306919.2 

(22) Date of filing: 29.09.1995 



(11) EP 0 704 792 B1 

EUROPEAN PATENT SPECIFICATION 

(51) lntCl7: G06F3/12 



(54) Method of managing memory allocation in a printing system 

Verfahren zur Verwaltung der Speicherzuweisung in einem Druckersystem 
M^thode de gestion d'allocation de m6moire dans un systdme d'impression 



m 

Csl 
O) 

O 
N 

O 

Q. 

LU 



(84) Designated Contracting States: 
DE FR GB 

(30) Priority: 29.09.1994 US 315274 

(43) Date of publication of application: 
03.04.1996 Bulletin 1996/14 

(73) Proprietor: XEROX CORPORATION 
Rochester, New York 14644 (US) 

(72) Inventors: 

• Ambalavanar, Samuel D. 
Rochester NY 14625 (US) 

• Romano, Kenneth D. 
Webster NY 14580 (US) 



• Sanford, Ronnie E. 
Webster NY 14580 (US) 

• Frumusa, Anthony M. 
Penfleld NY 14526 (US) 

• Diaz, Orlando 
Rochester NY 14620 (US) 

(74) Representative: Grtinecker, Kinkeldey, 

Stockmair & Schwanh3usser AnwaltssozietSt 
Maximilianstrasse 58 
80538 Munchen (DE) 



(56) References cited: 
EP-A- 0 550 158 



WO-A-91/06058 



Note: Within nine months from the publication of the mention of the grant of the European patent, any person may give 
notice to the European Patent Office of opposition to the European patent granted. Notice of opposition shall be filed in 
a written reasoned statement. It shall not be deemed to have been filed until the opposition fee has been paid. (Art. 
99(1) European Patent Convention). 



Printed by Jouve, 75001 PARIS (FR) 



1 



EP 0 704 792 B1 



2 



Description 

[0001] The present invention relates generally to a 
technique of memory management for a printing system 
and, more particularly, to a method of managing mem- 
ory allocation for the printing system which minimizes 
both processing overhead and memory fragmentation. 
[0002] Electronic printing systems typically include an 
input section, sometimes refen^ed to as an input Image 
terminal ("IIT"), a controller, sometimes referred to as 
an electronic subsystem ("ESS") and an output section 
or print engine, sometimes referred to as an image out- 
put temriinai ("lOP'). In one type of electronic printing 
system, manufactured by Xerox® Corporation, known 
as the DocuTech® electronic printing system, a job can 
be Inputted to the IITfrom, among other sources, a net- 
woric or a scanner. An example of an NT with both net- 
woric and scanner inputs is found in LIS-A-5, 170,340. 
[0003] Since digital printing systems store images 
electronically, a significant amount of memory is often 
required for storage. In a multifunctional digital printing 
system, various clients, i.e. various input/output devices 
of the printing system, seek to use the memory. That is, 
input clients seek to access the memory for storing im- 
age data and output clients seek to access the memory 
for the sake of consuming image data. Without some 
sort of arrangement for controlling employment of the 
memory by these clients, operation of the system can 
be impaired greatly. For example, a client with relatively 
slow processing capability can monopolize use of the 
memory at the expense of a client with relatively fast 
processing capability. Moreover, the memory needs of 
a group of clients may vary, among individual clients, 
over time. In the area of computer architecture, it is 
known that memory or resource management is a de- 
sirable approach for insuring that allocation of memory 
among a group of clients is perfonned In an orderiy man- 
ner 

[0004] US-A-5,21 2,566 is directed toward a resource 
allocation scheme for a memory arrangement including 
disk and system memories, the system memory includ- 
ing a plurality of buffers. A system state controller com- 
municates with the system memory, by way of a re- 
source manager, and with a scanner, by way of a scan 
management arrangement, the scan management ar- 
rangement including a scan scheduler and a scan con- 
troller. In operation, the scanner, along with each client 
requesting use of the system memory, is allocated a set 
of buffers. During run time, the scanner fills buffers al- 
located to it with scanned data of a scan job, obtained 
by reading a document, and stores each filled buffer out 
to disk. If the scanner requires more buffers than are 
allocated to It, then a fault will occur. In response to the 
fault, a fault command flows from the scan controller to 
the system state controller, which system state control- 
ler, in turn, transmits a control command requesting the 
resource manager to adjust buffer allocation in the sys- 
tem memory. Under ideal circumstances, the scanner 



receives the buffers it needs to complete the scan job. 
As disclosed, reallocation includes obtaining a previous- 
ly allocated buffer from a client other than the scanner. 
[0005] While the resource management scheme of 

5 US-A-5,21 2,566 patent is well suited for its intended 
purpose, it appears to require a fair amount of process- 
ing overhead since buffer allocation among clients must 
often be assessed in obtaining a free buffer for the scan- 
ner. It would be desirable to provide a resource man- 

10 agement scheme which uses a minimum amount of 
processing overhead in obtaining and providing memo- 
ry for a given client. Additionally, in the resource man- 
agement scheme of US-A-5,21 2,566, all of the buffers 
allocated to a given client may not be used fully. This 

*5 can lead to underutilization of memory space and even 
memory fragmentation. It would be desirable to provide 
a resource management scheme in which all memory 
space of the system memory is employed in the most 
efficient manner possible. 

20 [0006] Further, EP-A 0 550 158 describes a printing 
apparatus and printing control method wherein, when 
data is received from a first host computer, the printing 
apparatus stores the received data in a reception buffer 
that has been segmented into memory blocks of a pre- , 

25 scribed size. When one memory block is filled to capac- 
ity with data received from the first host computer, the 
printing apparatus determines whether there is print re- 
quest from another host computer. If there is a print re- 
quest from another host computer, reception of printing 

30 data accompanying this request is started, and the data 
is stored in an used memory block of the reception buff- 
er. When this memory block is filled to capacity, recep- 
tion of data from the first host computer is resumed. The 
printing apparatus receives data from a plurality of host 

35 computers concurrently and prints out data the recep- 
tion of which has ended. The printing apparatus is ca- 
pable of deciding the order of print out based not only 
upon the order in which print requests occur but also 
upon the size of data from each host computer. 

40 [0007] WO 91/06058 describes a storage and retriev- 
al system for document image data. A high-capacity and 
high-speed storage/retrieval system provides storage 
and retrieval for document images in digitised data fomi. 
Clusters of storage/retrieval modules receive serialised 

45 image optical data read from documents via point-to- 
point controllers. The storage/retrieval modules store or 
exchange digital data via individual controllers or line 
controllers in the clusters of the storage/retrieval mod- 
ules. A host computer is operative to transmit via server/ 

50 controller commands and management data to remotely 
located storage/retrieval modules. Local workstations 
are connected to the storage/retrieval modules via 
standard interface boards and remote workstations may 
be connected through modems and server/controller to 

55 other remote workstations. 

[0008] It is an object of the present invention to pro- 
vide a resource management scheme which uses a min- 
imum amount of processing overiiead in obtaining and 
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providing memory for a given client and employs all 
memory space of the memory in the most efficient man- 
ner possible. 

[0009] This object is solved by the method as claimed 
in independent claims 1 and 7. Preferred embodiments 
of the invention are subject-matters of dependent 
claims. 

[0010] In accordance with one aspect of the present 
invention there is provided a method of managing mem- 
ory allocation in a printing system with a controller and 
memory, the controller having a resource manager for 
managing use of the memory and the printing system 
supporting input clients, each input client seeking to 
store one or more images, in the fomi of image data, in 
the memory, comprising the steps of: partitioning at least 
a portion of the memory to create a plurality of blocks; 
providing each of the plurality of blocks with an identifier, 
each identifier indicating a location of a block in the 
memory; in response to a request from a selected input 
client, placing a first set of identifiers, con-esponding 
with a first set of blocks, in a database; accessing the 
first set of identifiers with the selected input client; filling 
up one or more of the first set of blocks, with image data, 
by referring to the first set of identifiers; transmitting an 
interrupt signal to the controller, with the selected input 
client, each time one of the first set of blocks is filled; 
and in response to a designated one of the blocks being 
filled, placing a second set of identifiers, con^esponding 
with a second set of blocks, in the database, so that 
when the selected input client has filled up a last one of 
the first set of blocks, the selected input client accesses 
the second set of blocks, by reference to the second set 
of identifiers and begins filling up a first block of the sec- 
ond set of blocks wherein memory allocation is accom- 
plished with a minimum amount of communication be- 
tween various components of the printing system. 
[0011] In accordance with another aspect of the 
present invention there is provided a method of manag- 
ing memory allocation in a printing system with an input 
client, the input client storing image data in memory for 
outputting an image associated with the image data, 
comprising the steps of: providing to the input client, a 
first set of blocks including a first block and a second 
block, wherein the second block includes a first part and 
a second part; filling up both the first block and the first 
part of the second block with image data, an end of the 
first part of the second block representing a con^espond- 
ing end of a first image; and filling up the second part of 
the second block with image data, the image data in the 
second part of the second block corresponding with a 
second image, wherein the first image is different than 
the second image and usage of memory space for stor- 
ing image data is maximized. 

[0012] These and other aspects of the invention will 
become apparent from the following description, the de- 
scription being used to illustrate a preferred embodi- 
ment of the invention when read in conjunction with the 
accompanying drawings, in which:- 



Figure 1 is a block diagram depicting a multifunc- 
tional, network adaptive printing machine; 
Figure 2 is a block diagram of a video control mod- 
ule for the printing machine of Figure 1 ; 
5 Figure 3 is a block diagram of a transfer module 
used in conjunction with the printing machine of Fig- 
ure 2; 

Figure 4 is a block diagram of a facsimile card used 
in conjunction with the printing machine of Figure 2; 
Figure 5 is a block diagram of a network controller 
for the printing machine of Figure 1 ; 
Figure 6 is a block diagram of a resource manage- 
ment scheme including a selected number of com- 
ponents from the block diagram of Figure 2; 
Figures 7-10 is a flow diagram illustrating some of 
the functionality of the resource management 
scheme of Figure 6; 

Figure 11 is a schematic representation of electron- 
ic precollation (EPC) memory being used in con- 
junction with the resource management scheme of 
the present invention; 

Figure 12 is a schematic representation illustrating 
how partial blocks are employed, in the resource 
management scheme, to reduce memory fragmen- 
tation; 

Figure 13 is a schematic representation of a data- 
base fomnat used in conjunction with the resource 
management scheme; and 
Figures 14-17 are schematic representations illus- 
trating how a combination of electronic precollation 
(EPC) and disk memory is used in conjunction with 
the resource management scheme. 

[0013] Refenring to Figure 1, a multifunctional, net- 
work adaptive printing system Is designated by the nu- 
meral 1 0. The printing system 1 0 includes a printing ma- 
chine 12 operatively coupled with a networic service 
module 14. The printing machine 12 includes an elec- 
tronic subsystem 1 6, referred to as a video control mod- 
ule (VCM), communicating with a scanner 18 and a 
printer 20. In one example, the VCM 16, which will be 
described in further detail below, coordinates the oper- 
ation of the scanner and printer in a digital copying ar- 
rangement. In a digital copying arrangement, the scan- 
ner 18 (also referred to as image input temriinal (NT)) 
reads an image on an original document by using a CCD 
full width array and converts analog video signals, as 
gathered, Into digital signals. In turn, an image process- 
ing system 22 (Figure 2), associated with the scanner 
1 8, executes signal correction and the like, converts the 
corrected signals into multi-level signals (e.g. binary sig- 
nals), compresses the multi-level signals and preferably 
stores the same in electronic precollation (EPC) mem- 
ory 24. 

[0014] Referring again to Figure 1 , the printer 20 (also 
referred to as image output tenninal (lOT)) preferably 
includes a xerographic print engine. In one example, the 
print engine has a multi-pitch belt (not shown) which is 
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written on with an imaging source, such as a synchro- 
nous source (e.g. laser raster output scanning device) 
or an asynchronous source (e.g. LED print bar). In a 
printing context, the multi-level image data Is read out 
of the EPC memory 24 (Figure 2) while the imaging 
source is turned on and off, in accordance with the im- 
age data, fomning a latent image on the photoreceptor. 
In turn, the latent image is developed with, for example, 
a hybrid jumping development technique and trans- 
ferred to a print media sheet. Upon fusing the resulting 
print, it may be inverted for duplexing or simply output- 
ted. It will be appreciated by those skilled in the art that 
the printer can assume other fomis besides a xero- 
graphic print engine without altering the concept upon 
which the disclosed embodiment is based. For example, 
the printing system 1 0 could be implemented with a ther- 
mal Inkjet or ionographic printer. 
[0015] Referring specifically to Figure 2, the VCM 16 
is discussed in further detail. The VCM 16 includes a 
video bus (VBus) 28 with which various I/O, data trans- 
fer and storage components communicate. Preferably, 
the VBus is a high speed, 32 bit data burst transfer bus 
which is expandable to 64 bit. The 32 bit implementation 
has a sustainable maximum bandwidth of approximate- 
ly 60 MBytes/sec. In one example, the bandwidth of the 
VBus is as high as 100 MBytes/sec. 
[0016] The storage components of the VCM reside in 
the EPC memory section 30 and the mass memory sec- 
tion 32. The EPC memory section includes the EPC 
memory 24, the EPC memory being coupled with the 
VBus by way of a DRAM controller 33. The EPC mem- 
ory, which is preferably DRAM, provides expansion of 
up to 64 MBytes, by way of two high density 32 bit SIMM 
modules. The mass memory section 32 includes a SCSI 
hard drive device 34 coupled to the VBus by way of a 
transfer module 36a. As will appear, other I/O and 
processing components are coupled respectively to the 
VBus by way of transfer modules 36. It will be appreci- 
ated that other devices (e.g. a workstation) could be 
coupled to the VBus by way of the transfer module 36a 
through use of a suitable interface and a SCSI line. 
[0017] Referring to Figure 3, the structure of one of 
the transfer modules 36 is discussed in further detail. 
The illustrated transfer module of Figure 3 includes a 
packet buffer 38, a VBus interface 40 and DMA transfer 
unit 42 . The transfer module 36, which was designed 
with "VHSIC" Hardware Description Language (VHDL), 
is a programmable an'angement permitting packets of 
image data to be transmitted along the VBus at a rela- 
tively high transfer rate. In particular, the packet buffer 
is programmable so that the segment or packet can be 
varied according to the available bandwidth of the VBus. 
In one example, the packet buffer can programmed to 
handle packets of up to 64 Bytes Preferably, the packet 
size would be reduced for times when the VBus is rela- 
tively busy and Increased for times when activity on the 
bus is relatively low. 

[0018] Adjustment of the packet size is achieved with 



the VBus interface 40 and a system controller 44 (Figure 
5). Essentially, the VBus Interface Is an arrangement of 
logical components, including, among others, address 
counters, decoders and state machines, which provides 
5 the transfer module with a selected degree of intelli- 
gence. The interface 40 communicates with the system 
controller to keep track of desired packet size and, in 
turn, this knowledge is used to adjust the packet size of 
the packet buffer 38, in accordance with bus conditions. 
10 That is, the controller, in view of its knowledge regarding 
conditions on the VBus 28, passes directives to the in- 
terface 40 so that the interface can adjust packet size 
accordingly. Further discussion regarding operation of 
the transfer module 36 is provided below 
15 [0019] More particularly, each DMA transfer unit em- 
ploys a conventional DMA transfer strategy to transfer 
the packets. In other words, the beginning and end ad- 
dresses of the packet are used by the transfer unit in 
implementing a given transfer. When a transfer is com- 
plete, the interface 40 transmits a signal back to the sys- 
tem controller 44 so that further infomnation, such as de- 
sired packet size and address designations, can be ob- 
tained. 

[0020] Referring to Figures 1 and 2, three I/O compo- 
nents are shown as being coupled operatively to the 
VBus 28, namely a FAX module 48, the scanner or IIT 
1 8, and the printer or lOT 20; however, it should be rec- 
ognized that a wide variety of components could be cou- 
pled to the VBus by way an expansion slot 50. Referring 
to Figure 4, an implementation for the F/VX module, 
which is coupled to the VBus 28 by way of transfer mod- 
ule 36b, is discussed in further detail. In the preferred 
embodiment, a facsimile device (FAX) 51 includes a 
chain of components, namely a section 52 for perform- 
ing Xerox adaptive compression/decompression, a sec- 
tion 54 for scaling compressed image data, a section 56 
for converting compressed Image data to or from CCITT 
fonnat, and a modem 58, preferably manufactured by 
Rockwell Corporation, for transmitting CCITT fonmatted 
data from or to a telephone, by way of a conventional 
communication line. 

[0021] Refemng still to Figure 4, each of the sections 
52, 54 and 56 as well as modem 58 are coupled with 
the transfer module 36b by way of a control line 60. This 
pemnits transfers to be made to and from the FAX mod- 
ule 48 without involving a processor. As should be un- 
derstood, the transfer module 36b can serve as a master 
or slave for the FAX module in that the transfer module 
can provide image data to the FAX for purposes of trans- 
mission or receive an incoming FAX. In operation, the 
transfer module 36b reacts to the FAX module in the 
same manner that it would react to any other I/O com- 
ponent. For example, to transmit a FAX job, the transfer 
module 36b feeds packets to the section 52 through use 
of the DMA transfer unit 42 and, once a packet is fed, 
the transfer module transmits an interrupt signal to the 
system processor 44 requesting another packet. In one 
embodiment, two packets are maintained in the packet 
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buffer 38 so that "ping-ponging" can occur between the 
two packets. In this way, the transfer module 36b does 
not run out of image data even when the controller can- 
not get back to it immediately upon receiving an inten'upt 
signal. 

[0022] Referring again to Figure 2, the IIT 1 8 and lOT 
20 are operatively coupled to the VBus 28 by way of 
transfer modules 36c and 36d. Additionally, the IIT 18 
and the lOT 20 are operatively coupled with a compres- 
sor 62 and a decompressor 64, respectively. The com- 
pressor and decompressor are preferably provided by 
way of a single module that employs Xerox adaptive 
compression devices. Xerox adaptive compression de- 
vices have been used for compression/decompression 
operations by Xerox Corporation in its DocuTech® print- 
ing system. In practice, at least some of the functionality 
of the transfer modules is provided by way of a 3 channel 
DVMA device, which device provides local arbitration for 
the compression/decompression module. 
[0023] As further Illustrated by Figure 2, the scanner 
18, which includes the image processing section 22, is 
coupled with an annotate/merge module 66. Preferably 
the image processing section includes one or more ded- 
icated processors programmed to perfomn various de- 
sired functions, such as image enhancement, threshold- 
ing/screening, rotation, resolution conversion and TRC 
adjustment. The selective activation of each of these 
functions can be coordinated by a group of image 
processing control registers, the registers being pro- 
grammed by the system controller 44. Preferably, the 
functions are arranged along a "pipeline" in which image 
data is inputted to one end of the pipe, and image proc- 
essed image data is outputted at the other end of the 
pipe. To facilitate throughput, transfer module 36e is po- 
sitioned at one end of the image processing section 22 
and transfer module 36c is positioned at another end of 
the section 22. As will appear, positioning of transfer 
modules 36c and 36e in this manner greatly facilitates 
the concurrency of a loopback process. 
[0024] Referring still to Figure 2, arbitration of the var- 
ious bus masters of the VCM 1 6 is implemented by way 
of a VBus arbiter 70 disposed In a VBus arbiter/bus gate- 
way 71 . The arbiter detemnines which bus master (e.g. 
FAX module, Scanner, Printer, SCSI Hard Drive, EPC 
Memory or Network Service Component) can access 
the VBus at one given time. The arbiter is made up of 
two main sections and a third control section. The first 
section, i.e., the "Hi-Pass" section, receives input bus 
requests and current priority selection, and outputs a 
grant corresponding to the highest priority request pend- 
ing. The current priority selection input Is the output from 
the second section of the arbiter and is referred to as 
"Priority Select". This section Implements priority rota- 
tion and selection algorithm. At any given moment, the 
output of the logic for priority select determines the order 
in which pending requests will be serviced. The input to 
Priority Select is a register which holds an initial place- 
ment of devices on a priority chain. On servicing re- 



quests, this logic moves the devices up and down the 
priority chain thereby selecting the position of a device's 
next request. Control logic synchronizes the tasks of the 
Hi-Pass and the Priority Select by monitoring signals re- 
5 garding request/grant activity. It also prevents the pos- 
sibility of race conditions. 

[0025] Refen-ingto Figures, the network service mod- 
ule 14 is discussed in further detail. As will be recog- 
nized by those skilled In the art, the architecture of the 

10 network service module is similar to that of a known "PC 
clone". More particularly, in the pretended embodiment, 
the controller 44, which preferably assumes the fonm of 
a SPARC processor, manufactured by Sun Microsys- 
tems, Inc., is coupled with a standard SBus 72. In the 

'5 illustrated embodiment of Figure 5, a host memory 74, 
which preferably assumes the form of DRAM , and a SC- 
SI disk drive device 76 are coupled operatively to the 
SBus 72. While not shown in Figure 5, a storage or I/O 
device could be coupled with the SBus with a suitable 

20 interface chip. As further shown in Figure 5, the SBus is 
coupled with a network 78 by way of an appropriate net- 
work interface 80. In one example, the network interface 
includes all of the hardware and software necessary to 
relate the hardware/software components of the control- 

25 ler 44 with the hardware/software components of the 
network 78. For instance, to interface various protocols 
between the networi< service module 1 4 and the networi< 
78, the network interface could be provided with, among 
other software. Netware® from Novell Corp. 

30 [0026] In one example, the network 78 includes a cli- 
ent, such as a wori<station 82 with an emitter or driver 
84. In operation, a user may generate a job Including a 
plurality of electronic pages and a set of processing in- 
structions. In turn, the job is converted, with the emitter, 

35 into a representation written In a page description lan- 
guage, such as PostScript. The job is then transmitted 
to the controller 44 where it is interpreted with a decom- 
poser, such as one provided by Adobe Corporation. 
[0027] Refen'ing again to Figure 2, the network serv- 

40 ice module 1 4 is coupled with the VCM 1 6 via a bus gate- 
way 88 of the VBus arbiter/bus gateway 71 . In one ex- 
ample, the bus gateway comprises a field programma- 
ble gate array provided by XILINX corporation. The bus 
gateway device provides the interface between the host 

45 SBus and the VCM VBus. It provides VBus address 
translation for accesses to address spaces in the VBus 
real address range, and passes a virtual address to the 
host SBus for virtual addresses in the host address 
range. A DMA channel for memory to memory transfers 

50 is also implemented in the bus gateway. Among other 
things, the bus gateway provides seamless access be- 
tween the VBus and SBus, and decodes virtual address- 
es from bus masters, such as one of the transfer mod- 
ules 36, so that an identifier can be obtained from a cor- 

55 responding slave component. It will be appreciated by 
those skilled in the art that many components of the 
printing system 10 are implemented In the form of a sin- 
gle ASIC. 
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[0028] Referring to Figures 2, 3 and 5, further discus- 
sion regarding DMA transfer of each of the transfer mod- 
ules 36 is provided. In particular, in one example, the 
images of a job are stored in the host memory 74 as a 
series of blocks. Referring to Figure 16, a series of 5 
blocks is shown as being stored in the EPC memory 24. 
Preferably, each block comprises a plurality of packets. 
In operation, one of the transfer modules 36 is provided, 
by the controller 44, with the beginning address of a 
block and the size of the block. In turn, for that block, 
the transfer module 36 effects a packet tranfer and in- 
crements/decrements a counter. This procedure is re- 
peated for each packet of the block until the interface 
40 determines, by reference to the counter, that the last 
packet of the block has been transferred. Typically, for 
each stored image, several blocks are transfen-ed, in a 
packet-by-packet manner, as described immediately 
above. 

[0029] Referring to Figure 6 a scheme for managing 
memory allocation, i.e. a resource management 
scheme, is illustrated. More particulariy, the controller 
44 includes a resource manager 300, while the host 
memory 74 includes a pair of lists 302, referred to re- 
spectively as the "free block list" and the "free partial 
block list", and a database ("db") 304. The resource 
manager Is implemented by way of suitable algorithms, 
the details of which will be discussed in further detail 
below, and the significance of the lists and the database, 
relative to the resource management scheme, will also 
be discussed below. Additionally, the EPC memory 24 
and the SCSI hard drive ("disk") 34 are shown as being 
comprised of blocks 306. A discussion of a methodology 
for forming and allocating memory blocks follows: 
[0030] Referring to Figures 6-10, the algorithms for 
implementing the resource management scheme are 
discussed. Initially, at step 308, the EPC memory 24 is 
partitioned into a series of the blocks 306. A partitioned 
set of memory blocks is also shown in Figure 11. Pref- 
erably, the block size is varied in accordance with fac- 
tors, such as image size to be stored. For example, if a 
location generally copies complex documents which re- 
sults in pooriy compressed (large) image, the block size 
can be increased. As will appear from the discussion 
below, increased block size will result in fewer inten^upts 
by a client (e.g. scanner 1 8) of the controller 44. 
[0031] Each block is then provided with identification 
infomnation (step 310), such as block ID, block address 
and block size, which identification infomiation is 
placed, at step 312, in the free block list. Preferably, 
each list in the host memory 74 is a linked list of struc- 
tures. At step 316, the resource management system 
waits for a memory request from a client. In the present 
context, a client Is an input or output device encom- 
passed by the printing system 10 (Figures 1 ,2 and 5). A 
client initiates a request by transmitting a suitable re- 
quest or inten^upt signal to the controller 44. Upon re- 
ceiving a request signal, the controller determines, via 
step 316, whether the client is an input client. If the client 



is an input client, then the process proceeds to step 31 8. 
othenwise the process proceeds directly to step 320 
(Figure 9) where an output client request is serviced. 
[0032] Assuming the requesting client is an input cli- 
ent, the resource manager 300 examines the free partial 
block list to determine if a partial block is available for 
the requesting client. Referring to Figure 12, an example 
of the allocation of a partial block to the beginning of an 
image will be discussed In particular, at system initiali- 
zation, no partial block is available for an image 1 of a 
job. After Image data for image 1 is delivered to the 
memory, however, a partial, unfilled block may remain. 
As shown in Figure 12, and explained in further detail 
below, the partially unfilled block, with its corresponding 
identifier is made available for use with the next Image. 
[0033] Returning to Figure 7, if a partial, unfilled block 
is available, then it is designated with an identifier and, 
at step 322, placed In the db 304. Next, at step 324, the 
resource manager consults the free block list to deter- 
mine if a nominal number of blocks are available for use 
by the input client. In the preferred embodiment, each 
client is assigned a value corresponding to the number 
of nominal blocks to which it is entitled. In one example, 
assignment is based on the processing speed of the re- 
questing client. That is, per each request, it may be de- 
sirable to provide fast processing clients with more 
blocks than slow processing clients. In one situation, the 
nominal number of blocks to be assigned a requesting 
client may not be available in the free block list. In this 
situation, the resource manager may provide the re- 
questing client with one or more partial blocks until a 
whole block becomes available. 
[0034] Assuming the nominal number of blocks is 
available, at step 326 the resource manager will place 
appropriate identifiers (i.e. Infomriation identifying both 
a first address and a size of each block) In the db 304. 
Refen'ing to Figure 13, a suitable database structure for 
use with the disclosed embodiment is shown. The data- 
base is constructed in a hierarchical scheme in which 
jobs are linked to images and images are linked to 
blocks. In one example, where the client's storable im- 
age data is associated with a first image (i.e. "Image 1) 
of a first job (i.e. "JOB 1"), then the first block identifier 
is placed at the location designated as "Block 1 Ad- 
dress". Subsequently, the client will access the data- 
base and, at step 328 (Figure 7), locate the address of 
the first available block. The client will then, In cooper- 
ation with, for example, one of transfer modules 36, fill 
up the located block. When the scanner is serving as 
the client, the scanner will initiate a DMA transfer, with 
EPC memory 24, via the transfer module 36D (Figure 
2). Referring again to Figure 14, the scanner is shown 
as using the EPC memory in conjunction with other cli- 
ents. While the block 306A is shown as being a whole 
block, it will be understood that, in many instances, it 
would be a partial block. 

[0035] The printing system 10 offers the advanta- 
geous feature of storing jobs, intended to be outputted 
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as multiple sets, on disk. In this way EPC memory can 
be made available to multiple clients in a relatively short 
time interval. Referring to step 332 of Figure 8, when 
disk storage is desired, each stored block is copied to 
disk 34 (also see step 334 of Figure 8). Referring to Fig- 
ure 14, a graphic representation demonstrating the re- 
lationship between EPC memory and disk is provided. 
[0036] As further shown in Figure 14, preferably, a 
minimum amount of input image pages, intended for 
printing, are buffered prior to printing. This has been 
found to be advantageous since a printer typically proc- 
esses image data at a rate much greater than that of 
most input clients, such as the scanner. In the illustrated 
embodiment of Figure 1 5, a variable buffer zone 336 is 
maintained for the scan client. This buffer zone is used 
to move image directly to disk, which enables the sys- 
tem to continue scanning without stopping. It will be ap- 
preciated that the variable zone can be used by clients, 
other than the scanner 1 8, to facilitate storage. 
[0037] Referring again to Figure 8, the input client 
transmits an inten-upt signal to the controller, at step 
338, when a block has been filled with image data. Al- 
ternatively, the input client could be provided, in ad- 
vance, with pointers to lists of block addresses. In this 
way, the input client would read, without controller Inter- 
vention, the locations of blocks to be used. 
[0038] A detemnination is made at step 340 as to 
whether a full image has been written into EPC memory 
24. Assuming that the end of the image has not been 
reached, it is determined, at step 342, whether another 
nominal number of blocks is required. It should be ap- 
preciated that, typically, when a client requires a nominal 
number of blocks, the resource manager provides it with 
a set of plural blocks. In application, those blocks follow 
a sequence and one of the blocks in the sequence is 
identified as a "relative last block" which, when reached, 
indicates that another set of blocks is required. The po- 
sition of the relative last block is variable in that it need 
not, in absolute temis, be the last block of the set. if the 
relative last block has not been reached, then the proc- 
ess loops back to step 328 where the db 304 (Figure 6) 
is accessed so that the client can locate the next block 
to be filled. On the other hand, if the relative last block 
has been reached, then the process loops back to step 
324 for obtaining at least a part of another block set. 
[0039] Referring still to Figure 8, if it is determined, at 
step 340, that a full Image has just been written into 
memory, then a series of steps is performed to prepare 
for the receiving of another image. First, the resource 
manager 300 (Figure 6) detennines, with step 344, if all 
of the full blocks have been used by the input client. If 
not, then the identifier of each surplus whole block is 
placed in the free block list (step 348), othenwise the 
process proceeds to step 350 where the resource man- 
ager detennines if the image ends on a partial block. 
Referring again to Figure 12, an example of how an im- 
age might end at a partial block is shown for the "Image 
1 In the preferred embodiment, the size of the unused 



part of Image 1 is then determined in accordance with 
step 352 of Figure 8. Referring to Figure 9, if the size of 
the partial block is greater than a selected minimum size 
(step 354), then an identifier is assigned to the partial 

5 block (step 356) and placed In the free partial block list 
so that the partial block can be used to receive image 
data from another image, such as the "Next Image" of 
Figure 1 2. For those cases in which a given partial block 
is smaller than a selected minimum, the given partial 

10 block Is saved for "gartsage collection", the significance 
of which will be described below. 
[0040] At steps 320 and 360, the preferred methodol- 
ogy accommodates for the needs of an output client, 
such as a printer. Regarding step 360, the output client 

15 is preferably "told" where the image data, intended for 
use in outputting, resides. In this way, the output client 
can read the image data from the EPC memory. Addi- 
tionally, as shown in Figure 14, an output operation can 
be executed just before or after an input operation. 

20 [0041] Referring to Figures 14, 16 and 17, an appli- 
cation of the the present memory management scheme, 
with respect to the printing client, is discussed in further 
detail. In the illustrated embodiments of Figures 14, 16 
and 17, a given job, intended to be printed in multiple 

25 sets, Is shown as including six images. In Figure 14, the 
first three Images are buffered and copied to disk. In Fig- 
ure 16, writing of images, to memory, continues concur- 
rent with the reading of first and second image blocks 
by the printer. While the read/write operations are not 

30 "concurrent", in absolute temns, they appear, to a sys- 
tem operator, as being concurrent. 
[0042] In Figure 17, the end of the job is written Into 
EPC memory at blocks 306B, 306C and 306D, while the 
beginning of the printing of a second set is initiated at 

35 block306E. Forthe printing ofthe second set, the Image 
2, along with the block for 1 D need not be copied from 
disk. As should be recognized, the EPC memory and 
disk function in a manner comparable to a ring buffering 
arrangement in that image data from disk can be written 

40 over image data in the EPC memory, continually, in or- 
der to form a desired number of sets. 
[0043] At step 362 (Figure 9), it is detennined whether 
an appropriate time has arrived for "garbage collection". 
In the present context, garbage collection refers to com- 

45 bining "spent blocks", i.e. blocks having image data al- 
ready "consumed" by an output client, for future use. In 
one example, a check for garbage collection is per- 
fomned after a predesignated number of images have 
been printed. More particulariy, garisage collection is 

50 perfomned as a background task, i.e. during a noncritical 
time of a job cycle. 

[0044] To implement garbage collection, the possibil- 
ity of block combination is checked at step 364 and par- 
tial blocks are combined, if possible, at step 366. It fol- 
55 lows that block combination constitutes, in one example, 
linking partial blocks with references. As blocks are 
fomnedfrom partial blocks (step 368), some partial block 
identifiers will be discarded and the resulting whole 
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block will be placed In the free block list. If garbage col- 
lection is not performable, the process proceeds to step 
372. 

[0045] At step 372, a check is perfonned to determine 
if the currently completed Image is the last image in the 
job. If the image is not the last image, then the process 
loops back to step 31 6 where the input/output client ac- 
cesses the db 304 for another block identifier, assuming 
that the client is ready. If, on the other hand, the job is 
complete, then a detemnination is made, at step 374, as 
to whether repartitioning is required. Repartitioning is 
performed (step 376) until a suitable block size is ob- 
tained. Subsequent to repartitioning the process loops 
back to step 31 6. 

[0046] Numerous features of the above-disclosed 
embodiment will be appreciated by those skilled in the 
art: 

[0047] First, the disclosed resource management 
scheme functions with a minimum amount of processing 
overhead. In particular, per a request by a client, block 
identifiers are placed at selected locations in a data- 
base. In turn, a selected client can access the database, 
detennine where available blocks exist in memory, by 
reference to the block identifiers, and begin filling those 
blocks. As the client fills the blocks, it signals a controller 
and, in response to the signals, the controller indicates 
to a resource manager when to place more block iden- 
tifiers in the database for the selected client. The proc- 
ess of providing blocks is transparent to the selected cli- 
ent and the resource manager is not required to pos- 
sesses any significant knowledge about memory alloca- 
tions of system clients in order to service the selected 
client appropriately. 

[0048] Second, memory utilization of the system is 
enhanced in that memory blocks are employed in a par- 
ticularly efficient manner. That is, unused blocks, wheth- 
er they be partial or whole blocks, are placed in one or 
more free lists as soon as a given client ceases to have 
an immediate need for them. In turn, unused free blocks 
are allocated to other clients, in an expeditious manner 
and partial blocks are, In many instances, used to store 
the beginning and end parts of an image. In this way 
memory fragmentation is minimized and memory space 
is made available to clients, who have an urgent de- 
mand for it, as soon as possible. 
[0049] Third, the resource management technique Is 
flexible in that a wide variety of system parameters, such 
as nominal block size, number of blocks allocated to a 
given client at one time, and block allocation timing are 
variable. In this way, the attendant printing system can 
accommodate for varying input/output demands. Pref- 
erably, the system can keep track of compression ratios 
and adjust the variables to maximize perfomnance for a 
particular location's majority usage. For example, if a lo- 
cation generally copies complex documents, which re- 
sults in poorly compressed (large) images, the block 
size can be Increased. Use of increased block size will 
result in fewer inten-upts to the controller. Moreover, the 



system can, among other things, adjust block allocation 
according to Individual client processing capability and 
predict the moment at which blocks, for a given client, 
should be made available. 

5 [0050] Finally, the resource management scheme 
can be used to colncidentally manage volatile and non- 
volatile memory in a manner that maximizes the func- 
tionality of the volatile memory, which volatile memory 
may be limited In space. Through efficient management 

10 of volatile and nonvolatile memory, even a job, having a 
size greater than that of the volatile memory (e.g. EPC 
memory) can be outputted in multiple sets with relatively 
little degradation In output rate. Moreover, volatile and 
nonvolatile memory can be used, conjunctively, to in- 

15 sure that even complex documents, having much great- 
er size than that of the volatile memory, can be stored 
by a given input client without impairing operation of that 
given input client. 



1 . A method of managing memory allocation in a print- 
ing system (10) comprising a controller (44) and 

25 memory (24, 34), the controller (44) having a re- 
source manager (300) for managing use of the 
memory (24, 34), at least a portion of the memory 
(24, 34) being partitioned into a plurality of blocks 
(306), the printing system (10) supporting input cli- 

30 ents(18),each inputclient (18) seeking to store one 
or more images, in the fomri of image data, in the 
memory (24, 34), 
characterized by: 

35 providing each block (306) with an identifier in- 

dicating a location of the block (306) in the 
memory (24, 34); 

in response to a request from one of the input 
40 clients (18), placing a first set of Identifiers, cor- 

responding with a first set of blocks (306), in a 
database (304); 

accessing the first set of identifiers with the in- 
45 put client (18); 

filling one or more blocks (306) of the first set 
of blocks (306), with image data from the input 
client (1 8), by referring to the first set of identi- 
50 fiers; 



transmitting an interrupt signal with the input cli- 
ent (1 8) to the controller (44), each time a block 
(306) of the first set of blocks (306) is filled; and 

in response to receiving the interrupt signal at 
the controller (44), placing a second set of iden- 
tifiers, corresponding with a second set of 
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blocks (306). in the database (304), in case that 
a predetermined blocl< (306) of the first set of 
blocl<s (306) has been filled, wherein the input 
client (18), after filling a last block (306) of the 
first set of blocks (306). is enabled to access 
the second set of blocks (306), by referring to 
the second set of identifiers, and to fill blocks 
(306) of the second set of blocks (306), thereby 
accomplishing memory allocation with a mini- 
mum amount of communication within the print- 
ing system (10). 

The method of claim 1 wherein said step of filling 
includes filling the first set of blocks (306) with im- 
age data generated from a scan service, the scan 
service including a scanning apparatus (1 8) for con- 
verting infomnation, disposed on a document, to the 
Image data. 
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providing the input client (18) with a first set of 
blocks (306) including a first block and a second 
block, the second block including a first part 
and a second part; 

filling both the first block and the first part of the 
second block with image data of the first image, 
an end of the first part of the second block rep- 
resenting a corresponding end of the first im- 
age; and 

filling the second part of the second block with 
image data of the second image, wherein the 
first image is different than the second image, 
thereby maximizing usage of memory space for 
storing image data. 

8. The method of claim 7, further comprising: 



3. The method of claim 1 or 2 wherein: 20 

the first set of blocks (306) includes a last block; 
and 

said step of placing the second set of identifiers 25 
includes placing the second set of identifiers in 
the database (304) after the last block has been 
filled with image data. 



4. The method of one of claims 1 to 3, further compris- 
ing: 

outputting a corresponding job, including one 
or both of the first and second sets of blocks (306), 
with an output client (20). 

5. The method of one of claims 1 to 4 wherein all of a 
filled block is used to print part of a conresponding 
job, further comprising: 

placing an identifier, associated with the used, 
• filled block, in a first list (302). 

6. The method of one of claims 1 to 5, furthercompris- 
ing: 

repartitioningthe memory (24, 34), after a pre- 
determined number of blocks (306) have been 
filled, for changing block size in accordance with 
varying image size of individual images being 
stored in memory (24. 34). 

7. A method of managing memory allocation in a print- 
ing system (10) comprising memory (24, 34), at 
least a portion of the memory (24, 34) being parti- 
tioned into a plurality of blocks (306), the printing 
system (10) supporting input clients (18), an input 
client (1 8) storing a first image and a second image, 
in the fonn of image data, in the memory (24, 34), 
characterized by: 



designating the second part of the second block 
with an identifier; and 

placing the identifier in a partial block list (302), 
said step of filling the second part including ac- 
cessing the partial block list (302), with the input 
client (1 8), to detemiine a space in memory (24, 
34) to which the image data of the second im- 
age is to be transmitted. 

30 9. The method of claim 7 or 8 wherein the first set of 
blocks (306) includes a third block, and the third 
block remains unfilled subsequent to the second 
part being filled, further comprising: 

35 designating the third block with an identifier; 

and 

accessing the third block identifier with the in- 
put client (1 8) for filling the third block with im- 
age data from the second image. 

1 0. The method of one of claims 7 to 9 wherein the input 
client (18) possesses a processing capability, and 
the first set of blocks (306) includes a predeter- 
mined number of blocks, further comprising: 
adjusting the predetemriined number of blocks (306) 
as a function of the processing capability of the input 
client (18). 

50 11. The method of one of claims 7 to 10 wherein said 
step of filling includes filling the first block (306) and 
the first part of the second block (306) with image 
data generated from a scan service, the scan serv- 
ice including a scanning apparatus (18)forconvert- 
55 ing information, disposed on a document, to the im- 
age data'. 
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PatentansprOche 

1. Verfahren zur Verwaltung der Speicherzuweisung 
in einem Drucksystem (10) mil Steuereinheit (44) 
und Speicher (24, 34), wobei die Steuereinheit (44) 
iiber einen Betriebsnnittelverwalter (300) zum Ver- 
walten des Speichers (24, 34) verfiigt, zumlndest 
ein Teil des Speicliers (24, 34) in sine Mehrzahl von 
Blocken (306) partitioniert ist und das Drucksystenn 
(10) Eingabe-Klienten (18) unterstutzt, wobei jeder 
Eingabe-Klient versuclit, ein Bild Oder mehrere Bil- 
der in Fomn von Bilddaten inn Speicher (24, 34) zu 
speichern, wobei das Verfahren gekennzelchnet 
ist durch: 

die Bereitstellung eines Identifiers fur jeden 
Block (306), der den Ort des Blocks (306) im 
Speicher (24, 34) angibt, 
das Platzieren eines ersten Identifier-Satzes, 
der einem ersten Satz von Blocken (306) ent- 
spricht, als Reaktion auf eine Anforderung von 
einem ersten Eingabe-Klienten (1 8) in eine Da- 
tenbank (304), 

den Zugriff auf den ersten Identifier-Satz nnit 
dem ersten Eingabe-Klienten (18), 
das Fullen eines oder mehrerer Blocke (306) 
aus dem ersten Satz Blocke (306) mit Bilddaten 
vom Eingabe-Klienten (18), indem auf den er- 
sten Identifier-Satz Bezug genommen wird, 
das Ubertragen eines Unterbrechungssignals 
mit dem ausgewahlten Eingabe-Klienten (18) 
an die Steuereinheit (44) immer dann, wenn ei- 
ner der Blocke (306) aus dem ersten Satz (306) 
gefullt ist, und 

das Platzieren eines zweiten Identifier-Satzes. 
der einem zweiten Satz von Blocken (306) ent- 
spricht, in die Datenbank (304), wenn ein vor- 
gegebener Block aus dem ersten Satz von 
Blocken (306) gefullt worden ist, wobei der Ein- 
gabe-Klient (18) nach dem Fullen eines letzten 
Blocks (306) aus dem ersten Satz von Blocken 
(306) in die Lage versetzt wird, auf den zweiten 
Satz von Blocken zuzugreifen, indem er auf 
den zweiten Identifier-Satz Bezug nimmt, und 
den zweiten Satz von Blocken (306) zu fullen, 
wodurch die Speicherzuweisung mit einem Mi- 
nimum an Kommunlkation zwischen einzelnen 
Komponenten des Drucksystems (10) erfolgt. 

2. Verfahren nach Anspruch 1 , wobei der Schritt des 
Fullens das Fullen des ersten Satzes von Blocken 
(306) mit von einem Scan-Service erzeugten Bild- 
daten umfasst, wobei der Scan-Service uber eine 
Scan-Vorrichtung (18) zum Umwandein der Infor- 
mationen auf einem Dokument In die Bilddaten ver- 
fugt. 

3. Verfahren nach Anspruch 1 oder 2, wobei 



der erste Satz von Blocken (306) einen letzten 
Block aufweist, und 

der Schritt des Platzierens des zweiten Identifier- 
Satzes das Platzieren des zweiten Satzes von Iden- 
5 tifiers in die Datenbank (304) umfasst, nachdem der 
letzte Block mit Bilddaten gefullt worden ist. 

4. Verfahren nach einem der Anspriiche 1 bis 3, wel- 
ches zudem die folgenden Schritte aufweist: 

10 die Ausgabe eines entsprechenden Jobs mit einem 
Oder beiden aus dem ersten und zweiten Satz von 
Blocken (306) mit einem Ausgabe-Klienten (20). 

5. Verfahren nach einem der Anspruche 1 bis 4, wobei 
15 ein gesamter gefiillter Block zum Drucken eines 

Teils eines entsprechenden Jobs verwendet wird 
und zu dem Verfahren weiterhin gehort: 
das Platzieren eines zu dem verwendeten, gefiillten 
Block gehorenden Identifiers in eine erste Liste 
20 (302). 

6. Verfahren nach einem der Anspruche 1 bis 5, wel- 
ches zudem umfasst: 

das emeute Partitionieren des Speichers (24, 34), 
25 nachdem eine vorgegebene Anzahl von Blocken 
(306) gefullt worden ist, damit die BlockgroBe ent- 
sprechend einer variierenden BildgroBe einzelner 
Bilder im Speicher (24, 34) verandert wird. 

30 7. Verfahren zur Verwaltung der Speicherzuweisung 
in einem Drucksystem (10) mit Speicher (24, 34), 
wobei zumlndest ein Teil des Speichers (24, 34) in 
eine Mehrzahl von Blocken (306) partitioniert wird, 
das Drucksystem (10) Eingabe-Klienten (18) unter- 

35 stutzt, ein Eingabe-Klient (18) ein erstes und ein 
zweites Bild in Form von Bilddaten im Speicher (24, 
34) speichert, wobei das Verfahren gekennzelch- 
net ist durch: die Bereitstellung eines ersten Sat- 
zes von Blocken (306) mit einem ersten und einem 

40 zweiten Block fur den Eingabe-Klienten (1 8), wobei 
der zweite Block einen ersten und einen zweiten 
Teil einschlieBt. das, Fullen sowohl des ersten 
Blocks als auch des ersten Teils des zweiten Blocks 
mit Bilddaten des ersten Bildes, wobei ein Ende des 

45 ersten Teils des zweiten Blocks ein entsprechendes 
Ende des ersten Bildes darstellt, und das Fullen des 
zweiten Teils des zweiten Blocks mit Bilddaten des 
zweiten Bildes, wobei sich das erste Bild von dem 
zweiten unterscheidet, wodurch der Speicherplatz 

50 zum Speichern von Bilddaten maximal ausgenutzt 
wird. 

8. Verfahren nach Anspruch 7, zu dem weiterhin ge- 
hort: 

55 

das Kennzeichnen des zweiten Teils des zwei- 
ten Blocks mit einem Identifier und 
das Platzieren des identifiers in eine Teilblock- 
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liste (302). wobei der Schritt des Fuilens des 
zweitens Teils das Auswerten der Teilblockliste 
(302) mit dem Eingabe-Klienten (18) ein- 
schlieBt, um dadurch einen Platz im Speicher 
(24, 34) 2U bestimmen, zu dem die Bilddaten 
des zweiten Biides ubertragen warden. 

9. Verfahren nach Anspruch 7 Oder 8, wobei der erste 
Satz von Blocken (306) einen dritten Block eln- 
schlieBt, und der dritte Block ungefuilt bleibt, nach- 
dem der zweite Teit gefiiltt worden 1st, welches wei- 
terhin umfasst: 

das Kennzelchnen des dritten Blocks mit einem 
Identifier und 

das Zugreifen auf den Identifier des dritten 
Blocks ifiit dem Eingabe-Klienten (1 8) zum Fiil- 
len des dritten Blocks mit Bilddaten vom zwei- 
ten Bild. 

1 0. Verfahren nach einem der Anspriiche 7 bis 9, wobei 
der Eingabe-Klient (18) ein Verarbeitungsvermo- 
gen besitzt und der erste Satz von Blocken (306) 
eine vorgegebene Anzahl von Blocken einschlleBt, 
welches weiterhin umfasst: 

das Einstellen einer vorgegebenen Anzahl 
von Blocken (306) als Funktion des Verarbeitungs-, 
vemnogens des Eingabe-Klienten (18). 

1 1 . Verfahren nach einem der Anspriiche 7 bis 1 0, wo- 
bei zum Schritt des Fuilens das Fullen des ersten 
Blocks (306) und des ersten Teils des zweiten 
Blocks (306) mit von einem Scan-Service erzeug- 
ten Bilddaten gehort, wobei der Scan-Service eine 
Scan-Vorrichtung (18) zum.UmwandeIn von Infor- 
mationen auf einem Dokument In die Bilddaten auf- 
weist. 



Revendications 

1. Precede de gestion d'une allocatton de m§molre 
dans un syst6me d'impression (1 0) comprenant un 
controleur (44) et une m6moire (24, 34), le contro- 
leur (44) comportant un gestionnaire de ressources 
(300) destin6 k g6rer I'utliisation de la m6moire (24, 
34), au molns une partie de la m6moire (24, 34) 
etant segment^e en une plurality de blocs (306), le 
syst6me d'impression (1 0) acceptant des clients en 
entree (1 8). chaque client en entree (18) cherchant 
k m^moriser une ou plusieurs images, sous fonne 
de donn§es d'image, dans la m6moire (24, 34), ca- 
ract^ris^ par les etapes suivantes : 

foumir k chaque bloc (306) un identif icateur in- 
diquant un emplacement du bloc (306) dans la 
m§moire (24, 34), 

en r§ponse k une demande provenant de I'un 



des clients en entr6e (18), placer un premier 
ensemble d'ldentlficateurs, correspondant k un 
premier ensemble de blocs (306), dans une ba- 
se de donn6es (304), 

5 acceder au premier ensemble d'identificateurs 

avec le client en entree (18), 
remplir un ou plusieurs blocs (306) du premier 
ensemble de blocs (306), avec des donn§es 
d'image provenant du client en entree (18), en 

10 se r^ferant au premier ensemble d'identifica- 

teurs, 

transmettre un signal d'internjption avec le 
client en entr6e (18) au contr6leur (44) k cha- 
que fois qu'un bloc (306) du premier ensemble 

15 de blocs (306) est rempli, et 

en reponse k la reception du signal d'interrup- 
tion au niveau du contr6leur (44), placer un se- 
cond ensemble d'identificateurs, correspon- 
dant k un second ensemble de blocs (306), 

20 dans la base de donn^es (304), dans le cas ou 

un bloc pred§temiine (306) du premier ensem- 
ble de blocs (306) a et§ rempli, dans lequel le 
client en entr§e (18) apres le remplissage d'un 
dernier bloc (306) du premier ensemble de 

25 blocs (306), est autoris6 a acceder au second 

ensemble de blocs (306), en se r6ferant au se- 
cond ensemble d'identificateurs, et k remplir 
des blocs (306) du second ensemble de blocs 
(306), 

30 en accomplissant ainsi une allocation de me- 

moire avec une quantity minimum de commu- 
nications a rinterieur du systeme d'impression 
(10). 

55 2. Proc6d6 selon la revendication 1 , dans lequel : la- 
dite §tape de remplissage comprend le remplissage 
du premier ensemble de blocs (306) avec des don- 
nees d'image generees a partir d'un service de nu- 
m§risation, le service de num^risatton comprenant 

40 un dispositif de numerisation (1 8) destine k conver- 
tir des infomiations, dispos6es sur un document, en 
donnees d'image. 

3. Proc§de selon la revendication 1 ou 2, dans lequel ; 

45 

le premier ensemble de blocs (306) comprend 
un dernier bloc, et 

ladite 6tape consistant k placer le second en- 
semble d'identificateurs comprend le fait de 
50 placer le second ensemble d'identificateurs 

dans la base de donnees (304) apr^s que le 
demier bloc a 6t§ rempli avec des donn§es 
d'image. 

55 4. Proc6d6 selon I'une des revendications 1^3, com- 
prenant en outre : 

lafourniture en sortie d'une tSche correspon- 
dante, comprenant un ou plusieurs des premier et 



11 



21 



EP 0 704 792 B1 



22 



second ensembles de blocs (306). avec un client 
en sortie (20). 

5. Proc6d6 selon I'une des revendicatlons 1 k 4, dans 
lequel la totality d'un bloc renapli est utilisee pour 5 
imprinner une partie d'une t§che correspondante, 
comprenant en outre : 

le fait de placer un identificateur, associ6 au 
bloc rempli utilise, dans une premiere liste (302). 

10 

6. Procede selon I'une des revendications 1 k 5, com- 
prenant en outre : 

un nouveau cloisonnement de la m6moire 
(24, 34), apresqu'un nombrepr6d6tennln6de blocs 
(306) ont ete remplis, en vue de modifier la taille is 
des blocs confomnement k une taille d'image varia- 
ble des images Individuelles qui sont m§morisees 
dans une memoire (24, 34). 

7. Precede de gestlon d'une allocation de memoire 20 
dans un systeme d'impression (10) comprenant 
une memoire (24, 34), au moins une partie de la 
memoire (24, 34) etant cloisonnee en une plurality 

de blocs (306), le systfeme d'impression (1 0) accep- 
tant des clients en entr§e (18), un client en entree 25 
(1 8) memorisant une premiere image et une secon- 
de image, sous fonrie de donn^es d'image, dans la 
m6moire (24, 34), caract6ris6 par les 6tapes 
suivantes : 

30 

foumir au client en entree (18) un premier en- 
semble de blocs (306) comprenant un premier 
bloc et un second bloc, le second bloc compre- 
nant une premiere partie et une seconde partie, 
remplir k la fois le premier bloc et la premiere 35 
partie du second bloc avec des donn§es d'ima- 
ge de la premiere image, une extr6mit6 de la 
premiere partie du second bloc representant 
une extr6mit6 correspondante de la premiere 
image, et 40 
remplir la seconde partie du second bloc avec 
des donn^es d'Images de la seconde image, 
dans laquelle la premiere Image est differente 
de la seconde image en maximisant ainsi I'uti- 
lisation de I'espace memoire pour memoriser ^5 
les donn^es d'image. 

8. Proc6d§ selon la revendication 7, comprenant en 
outre : 



nees d'image de la seconde image doivent etre 
transmlses. 

9. Proc6d6 selon la revendication 7 ou 8, dans lequel 
le premier ensemble de blocs (306) comprend un 
troisi^me bloc, et le troisi^me bloc reste non rempli 
apr^s que la seconde partie est remplie, compre- 
nant en outre : 

la designation du troisi^me bloc avec un iden- 
tificateur, et 

un acces k I'identlficateur du troisieme bloc 
avec le client en entr6e (1 8) en vue de remplir 
le troisieme bloc avec des donn^es d'image 
provenant de la seconde image. 

10. Proced6 selon I'une des revendications 7 a 9, dans 
lequel le client en entree (1 8) poss§de une capacite 
de traitement, et le premier ensemble de blocs 
(306) comprend un nombre predetemriine de blocs, 
comprenant en outre : 

I'ajustement du nombre predetermine de 
blocs (306) en fonction de la capacite de traitement 
du client en entree (18). 

1 1 . Precede selon I'une des revendications 7 a 1 0, dans 
lequel ladite etape de remplissage comprend le 
remplissage du premier bloc (306) et de la premiere 
partie du second bloc (306) avec des donn6es 
d'image g§n6r6es k partir d'un service de numerl- 
sation, le service de numerlsation comprenant un 
dispositif de num6rlsation (18) destine k convertir 
des infomnations, dispos^es sur un document, en 
les donnees d'image. 



la designation de la seconde partie du second 
bloc par un Identificateur, et 
le fait de placer Tidentif icateur dans une liste de 
blocs partiels (302), ladite etape de remplissa- 
ge de la seconde partie comprenant un acces 55 
k la liste des blocs partiels (302). avec le client 
en entree (18), afin de detemiiner un espace 
dans la memoire (24, 34) vers lequel les don- 
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